Skip to content

feat(triage-security): add early assignment and Assigned transition at Step 0.7#221

Merged
mrizzi merged 2 commits into
RHEcosystemAppEng:mainfrom
ruromero:TC-5008
Jul 2, 2026
Merged

feat(triage-security): add early assignment and Assigned transition at Step 0.7#221
mrizzi merged 2 commits into
RHEcosystemAppEng:mainfrom
ruromero:TC-5008

Conversation

@ruromero

@ruromero ruromero commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Add Step 0.7 to triage-security that assigns the CVE Vulnerability issue to the triaging user and transitions to Assigned status immediately after JIRA Access initialization
  • Transitions are discovered dynamically via get_transitions to support the Vulnerability workflow (Assigned status, not In Progress)
  • Remove redundant Case C assignment (now covered by the early step)
  • Add eval assertion to eval-1 verifying the early assignment behavior
  • Fix eval-1 prompt to explicitly request Step 0.7 output so the assertion can pass (TC-5011)

Implements TC-5008

Test plan

  • Grep SKILL.md for Step 0.7 heading — exists between Step 0.5 and Step 1
  • Grep SKILL.md for user_info and assignee in the new step — both present
  • Grep SKILL.md for get_transitions in the new step — dynamic discovery present
  • Verify Case C no longer contains standalone assignment
  • Eval assertion added to eval-1 covering early assignment behavior
  • Eval-1 prompt updated to request Step 0.7 output in data-extraction.md

🤖 Generated with Claude Code

Summary by Sourcery

Introduce an early triage step that immediately assigns CVE Vulnerability issues to the triaging user and transitions them to Assigned status after Jira access initialization.

Enhancements:

  • Add a new early workflow step (0.7) to assign Vulnerability issues to the current user and transition them to Assigned via dynamically discovered Jira transitions.
  • Remove the later Case C assignment step now that assignment happens earlier in the workflow.

Documentation:

  • Expand triage-security SKILL.md with detailed instructions for Step 0.7, including user_info lookup, issue assignment, and dynamic transition discovery semantics.

Tests:

  • Update triage-security evals to include an assertion verifying the new early assignment and Assigned transition behavior.

…t Step 0.7

Add Step 0.7 between JIRA Access (0.5) and Data Extraction (1) to assign the
CVE Vulnerability issue to the triaging user and transition to Assigned status.
This provides visibility into active triage and enables concurrent triage
detection in Step 7. Transitions are discovered dynamically via get_transitions
to support the Vulnerability workflow (which uses Assigned, not In Progress).
Remove the redundant Case C assignment that the early step now covers.

Implements TC-5008

Assisted-by: Claude Code
@sourcery-ai

sourcery-ai Bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Reviewer's Guide

Adds a new early triage step (0.7) that assigns the CVE Vulnerability issue to the current user and transitions it to Assigned via dynamically discovered Jira transitions, removes a now-redundant late assignment in Case C, and extends the triage-security evals to assert the new behavior.

Sequence diagram for Step 0.7 early assignment and Assigned transition

sequenceDiagram
  actor User
  participant triage_security_skill
  participant Jira

  User->>triage_security_skill: start Step_0_7_Assign_and_Transition
  triage_security_skill->>Jira: user_info()
  Jira-->>triage_security_skill: current_user_account_id

  triage_security_skill->>Jira: edit_issue(jira_issue_id, assignee=current_user_account_id)

  triage_security_skill->>Jira: get_transitions(jira_issue_id)
  Jira-->>triage_security_skill: transitions_list

  triage_security_skill->>triage_security_skill: [select transition with status Assigned]

  alt issue_status_is_New
    triage_security_skill->>Jira: transition_issue(jira_issue_id, assigned_transition_id)
  else issue_status_not_New
    triage_security_skill->>triage_security_skill: [skip transition, keep assignment]
  end
Loading

File-Level Changes

Change Details Files
Introduce Step 0.7 to perform early assignment and dynamic transition to Assigned in the triage-security skill.
  • Extend the triage step table with a new 0.7 step describing early assignment and transition to Assigned.
  • Add a detailed Step 0.7 section that retrieves the current user via jira.user_info, assigns via jira.edit_issue, discovers transitions via jira.get_transitions, and conditionally transitions via jira.transition_issue.
  • Clarify behavior when the issue is already in Assigned or a later status, keeping assignment but skipping the transition.
plugins/sdlc-workflow/skills/triage-security/SKILL.md
Remove redundant late assignment from Case C now that assignment happens in Step 0.7.
  • Delete the explicit "Assign to current user" instruction from Case C workflow steps.
plugins/sdlc-workflow/skills/triage-security/SKILL.md
Update triage-security eval configuration to assert the new early assignment behavior.
  • Add or modify eval entries to cover early assignment and Assigned transition semantics for Step 0.7.
  • Ensure eval-1 (or equivalent) includes an assertion that the vulnerability issue is assigned to the triaging user after Jira access initialization.
evals/triage-security/evals.json

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • Consider documenting how to handle cases where jira.user_info() or jira.get_transitions() fails or returns no matching "Assigned" transition so the skill has a clear fallback behavior.
  • The new Step 0.7 assumes a single transition to an "Assigned" status; if multiple transitions target "Assigned", it may be worth specifying how to choose among them to avoid ambiguous behavior.
  • Early assignment in Step 0.7 could race with other concurrent triage workflows; consider briefly noting how this step interacts with Step 7’s concurrent triage detection to avoid conflicting assignments.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- Consider documenting how to handle cases where `jira.user_info()` or `jira.get_transitions()` fails or returns no matching "Assigned" transition so the skill has a clear fallback behavior.
- The new Step 0.7 assumes a single transition to an "Assigned" status; if multiple transitions target "Assigned", it may be worth specifying how to choose among them to avoid ambiguous behavior.
- Early assignment in Step 0.7 could race with other concurrent triage workflows; consider briefly noting how this step interacts with Step 7’s concurrent triage detection to avoid conflicting assignments.

## Individual Comments

### Comment 1
<location path="plugins/sdlc-workflow/skills/triage-security/SKILL.md" line_range="222-231" />
<code_context>
+2. **Assign the issue to the current user:**
+
+   ```
+   jira.edit_issue(<jira-issue-id>, assignee=<current-user-account-id>)
+   ```
+
+3. **Discover the target transition dynamically:**
+
+   ```
+   jira.get_transitions(<jira-issue-id>)
+   ```
+
+   Select the transition whose target status name is `"Assigned"`. Do NOT
+   hardcode a transition ID or assume the transition name — Vulnerability issues
+   use a different Jira workflow than Task issues.
+
+4. **Transition to Assigned (if the issue is in New status):**
+
+   ```
+   jira.transition_issue(<jira-issue-id>, <assigned-transition-id>)
+   ```
+
+   If the issue is already in Assigned or any later status (detected via the
+   status-aware handling in the Inputs section), skip the transition silently.
+   The assignment in step 2 still proceeds regardless — it ensures the current
+   user is recorded even when re-triaging an issue that was previously assigned.
+
</code_context>
<issue_to_address>
**suggestion:** Clarify the relationship between the "Vulnerability issue key" input and the `<jira-issue-id>` placeholder used in examples.

The Inputs section uses the term "Vulnerability issue key," while these examples use `<jira-issue-id>`. Please briefly clarify whether the issue key is passed directly as `<jira-issue-id>` or how it is converted, so readers know exactly what value to supply in these calls.

Suggested implementation:

```
2. **Assign the issue to the current user:**

   The `<jira-issue-id>` placeholder in these examples is the same value as the
   "Vulnerability issue key" input (for example, `SEC-1234`) and should be passed
   directly to the Jira client methods without additional conversion.

   ```
   jira.edit_issue(<jira-issue-id>, assignee=<current-user-account-id>)
   ```

3. **Discover the target transition dynamically:**

   ```
   jira.get_transitions(<jira-issue-id>)
   ```

```

```
4. **Transition to Assigned (if the issue is in New status):**

   Use the same "Vulnerability issue key" value as `<jira-issue-id>` here as
   well (for example, `SEC-1234`):

   ```
   jira.transition_issue(<jira-issue-id>, <assigned-transition-id>)
   ```

   If the issue is already in Assigned or any later status (detected via the
   status-aware handling in the Inputs section), skip the transition silently.
   The assignment in step 2 still proceeds regardless — it ensures the current
   user is recorded even when re-triaging an issue that was previously assigned.

```

If the Inputs section currently uses a different label (for example, "Vulnerability issue key (e.g., SEC-1234)"), you may want to cross-link explicitly, such as: “This is the same value provided as the ‘Vulnerability issue key’ input in the Inputs section.” Adjust the example key format (`SEC-1234`) if your Jira project uses a different key prefix or format.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +222 to +231
jira.edit_issue(<jira-issue-id>, assignee=<current-user-account-id>)
```

3. **Discover the target transition dynamically:**

```
jira.get_transitions(<jira-issue-id>)
```

Select the transition whose target status name is `"Assigned"`. Do NOT

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Clarify the relationship between the "Vulnerability issue key" input and the <jira-issue-id> placeholder used in examples.

The Inputs section uses the term "Vulnerability issue key," while these examples use <jira-issue-id>. Please briefly clarify whether the issue key is passed directly as <jira-issue-id> or how it is converted, so readers know exactly what value to supply in these calls.

Suggested implementation:

2. **Assign the issue to the current user:**

   The `<jira-issue-id>` placeholder in these examples is the same value as the
   "Vulnerability issue key" input (for example, `SEC-1234`) and should be passed
   directly to the Jira client methods without additional conversion.

jira.edit_issue(, assignee=)


3. **Discover the target transition dynamically:**

jira.get_transitions()


4. **Transition to Assigned (if the issue is in New status):**

   Use the same "Vulnerability issue key" value as `<jira-issue-id>` here as
   well (for example, `SEC-1234`):

jira.transition_issue(, )


If the issue is already in Assigned or any later status (detected via the
status-aware handling in the Inputs section), skip the transition silently.
The assignment in step 2 still proceeds regardless — it ensures the current
user is recorded even when re-triaging an issue that was previously assigned.

If the Inputs section currently uses a different label (for example, "Vulnerability issue key (e.g., SEC-1234)"), you may want to cross-link explicitly, such as: “This is the same value provided as the ‘Vulnerability issue key’ input in the Inputs section.” Adjust the example key format (SEC-1234) if your Jira project uses a different key prefix or format.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[sdlc-workflow/verify-pr] Classified as suggestion — this proposes clarifying placeholder naming conventions, which is not documented in CONVENTIONS.md and has no established codebase-wide convention (angle-bracket placeholders like <jira-issue-id> are used consistently throughout all skill files). No sub-task created.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eval Results

Eval Results: triage-security

Eval Passed Failed Pass Rate
eval-1 11/11 0 100%
eval-10 5/5 0 100%
eval-11 5/5 0 100%
eval-12 5/5 0 100%
eval-13 5/5 0 100%
eval-14 5/5 0 100%
eval-15 5/5 0 100%
eval-16 7/7 0 100%
eval-17 5/5 0 100%
eval-19 5/5 0 100%
eval-2 5/5 0 100%
eval-20 4/4 0 100%
eval-21 4/4 0 100%
eval-22 4/4 0 100%
eval-23 4/4 0 100%
eval-24 4/4 0 100%
eval-25 4/4 0 100%
eval-3 5/5 0 100%
eval-4 5/5 0 100%
eval-5 6/6 0 100%
eval-6 6/6 0 100%
eval-7 5/5 0 100%
eval-8 5/5 0 100%
eval-9 5/5 0 100%

Pass rate: 100% · Tokens: 0 · Duration: 0s

Baseline (8b288dc2): 99% · 45,946 tokens · 89s


Generated by sdlc-workflow/run-evals v0.11.1

@ruromero

ruromero commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator Author

[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — Classified as suggestion (3 items):

  1. Fallback behavior for jira.user_info()/get_transitions() failures — suggestion. Step 0.5 already handles JIRA access failures via the shared jira-access-strategy.md protocol. No CONVENTIONS.md convention prescribes additional error handling in skill steps. No sub-task created.

  2. Multiple transitions targeting "Assigned" — suggestion. Jira workflows typically have a single transition to a given target status. No convention governs transition disambiguation. No sub-task created.

  3. Step 0.7 / Step 7 interaction — suggestion. Step 0.7 already documents its relationship to Step 7 ("enables Step 7 (Concurrent Triage Detection) to reliably identify active work"). The race scenario is mitigated by the assignment + transition making concurrent work visible. No sub-task created.

@ruromero

ruromero commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator Author

Verification Report for TC-5008 (commit 66f2019)

Check Result Details
Review Feedback PASS 4 suggestions classified, no code change requests
Root-Cause Investigation DONE Convention gap: eval prompt-assertion coherence rule (TC-5012)
Scope Containment PASS PR files exactly match task spec (2/2)
Diff Size PASS +43/-2 across 2 files, proportionate
Commit Traceability PASS Commit references TC-5008
Sensitive Patterns PASS No secrets detected
CI Status PASS All 4 checks pass
Acceptance Criteria PASS 5 of 5 criteria met
Test Quality WARN Eval Quality: WARN — eval-1 at 91% (10/11), 1 regression; Repetitive Test: N/A; Test Doc: N/A
Test Change Classification N/A No test files in PR
Verification Commands N/A No commands specified

Overall: PASS

All functional checks pass. The eval-1 assertion failure (Step 0.7 not demonstrated in eval output) is tracked as TC-5011. Root-cause analysis identified a convention gap — the eval prompt was not updated to request Step 0.7 output, tracked as TC-5012.

Note: Test Quality and Root-Cause Investigation are informational and do not affect the Overall result.


This comment was AI-generated by sdlc-workflow/verify-pr v0.11.0.

The eval-1 assertion for Step 0.7 (early assignment) was failing because
the prompt never requested Step 0.7 output from the model. Updated the
prompt to explicitly request Step 0.7 actions in data-extraction.md and
adjusted the assertion wording for dry-run compatibility.

Implements TC-5011

Assisted-by: Claude Code
@ruromero ruromero requested a review from mrizzi July 1, 2026 15:51
@ruromero

ruromero commented Jul 1, 2026

Copy link
Copy Markdown
Collaborator Author

Verification Report for TC-5008 (commit 3786033)

Check Result Details
Review Feedback PASS 4 suggestions, 0 code change requests
Root-Cause Investigation N/A No sub-tasks created
Scope Containment PASS PR files match task spec exactly (2/2)
Diff Size PASS 33 additions, 4 deletions across 2 files — proportionate
Commit Traceability WARN 1/2 commits reference TC-5008; commit 3786033 references TC-5011 (eval fix sub-task)
Sensitive Patterns PASS No secrets detected
CI Status PASS All CI checks pass (Plugin Validation, Sourcery review, Eval Dispatch)
Acceptance Criteria PASS 5/5 criteria met
Test Quality PASS Eval Quality: PASS (100%, 24/24 evals, 0 failures); baseline 99% at 8b288dc
Test Change Classification N/A No test files in PR
Verification Commands N/A No verification commands specified

Overall: WARN

Commit 3786033 references TC-5011 instead of TC-5008. TC-5011 is an eval fix sub-task created during the first verification run and its commit was pushed to this PR branch. This is expected cross-task tracing within the same PR — no action required.


This comment was AI-generated by sdlc-workflow/verify-pr v0.11.0.

@mrizzi mrizzi left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ruromero assigning issues is a must-have, thanks

@mrizzi mrizzi merged commit 90b8e2a into RHEcosystemAppEng:main Jul 2, 2026
4 checks passed
@ruromero ruromero deleted the TC-5008 branch July 2, 2026 07:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants